Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Conclusion

These examples show most of the important principles of defining business logic for SBOs:

The SBO supports the same four server-side hooks for logic as the SDO:
preTransactionValidate, for validation checks or changes to be made to the updated records before the transaction starts.
beginTransactionValidate, for changes to be made to other related database records, or to lock one or more related records for the duration of the transaction.
endTransactionValidate, for logic that must look at the state of the database after all the updates have been applied.
postTransactionValidate, for any logic that must execute after the execution has completed.
The SBO can refer to all of the updates in all of the SDOs, using the logical ObjectName that has been given to each SDO.
All of the logic in the individual SDOs continues to be executed when they are used within an SBO.
The SBO can return error messages just as the SDOs can.
Any changes made by the business logic of the SBO are seen by the SDOs when they execute the validation procedure of the same name.
Any changes made to the updated records by the SBO are seen back on the client at the end of the transaction, just as changes made by the SDOs, or by database trigger procedures, are seen.